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Abstract 


This document describes Time To Live (TTL) processing in hierarchical 
Multi-Protocol Label Switching (MPLS) networks and is motivated by 
the need to formalize a TTL-transparent mode of operation for an MPLS 
label-switched path. It updates RFC 3032, "MPLS Label Stack 
Encoding". TTL processing in both Pipe and Uniform Model 
hierarchical tunnels are specified with examples for both "push" and 
"pop" cases. The document also complements RFC 3270, "MPLS Support 
of Differentiated Services" and ties together the terminology 
introduced in that document with TTL processing in hierarchical MPLS 
networks. 


Conventions used in this document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC-2119]. 

1. Introduction and Motivation 
This document describes Time To Live (TTL) processing in hierarchical 
MPLS networks. We believe that this document adds details that have 


not been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods 
presented in this document complement [MPLS-DS]. 
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In particular, a new mode of operation (referred to as the Pipe 
Model) is introduced to support the practice of configuring MPLS LSPs 
such that packets transiting the LSP see the tunnel as a single hop 
regardless of the number of intermediary label switch routers (LSR). 
The Pipe Model for TTL is currently being used in multiple networks 
and is provided as an option configurable by the network operator by 
several vendors. 


This document formalizes the TTL processing in MPLS networks and ties 
it with the terminology introduced in [MPLS-DS]. 


2. TTL Processing in MPLS Networks 
2.1. Changes to RFC 3032 [MPLS-ENCAPS] 


a) [MPLS-ENCAPS] only covers the Uniform Model and does NOT address 
the Pipe Model or the Short Pipe Model. This document addresses 
these two models and for completeness will also address the 
Uniform Model. 


b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This document 
addresses this issue. 


c) [MPLS-ENCAPS] does not define TTL processing in the presence of 
Penultimate Hop Popping (PHP). This document addresses this 
issue. 


2.2. Terminology and Background 


As defined in [MPLS-ENCAPS], MPLS packets use a MPLS shim header that 
indicates the following information about a packet: 


MPLS Label (20 bits) 

TTL (8 bits) 

Bottom of stack (1 bit) 
Experimental bits (3 bits) 


aap 


The experimental bits were later redefined in [MPLS-DS] to indicate 
the scheduling and shaping behavior that could be associated with an 
MPLS packet. 


[MPLS-DS] also defined two models for MPLS tunnel operation: Pipe and 
Uniform Models. In the Pipe Model, a MPLS network acts like a 
circuit when MPLS packets traverse the network such that only the LSP 
ingress and egress points are visible to nodes that are outside the 
tunnel. A Short variation of the Pipe Model is also defined in 
[MPLS-DS] to differentiate between different egress forwarding and 
QoS treatments. On the other hand, the Uniform Model makes all the 
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nodes that a LSP traverses visible to nodes outside the tunnel. We 
will extend the Pipe and Uniform Models to include TTL processing in 
the following sections. Furthermore, TTL processing, when performing 
PHP, is also described in this document. For a detailed description 
of Pipe and Uniform Models, please see [MPLS-DS]. 


TTL processing in MPLS networks can be broken down into two logical 
blocks: (i) the incoming TTL determination to take into account any 
tunnel egress due to MPLS Pop operations; (ii) packet processing of 
(possibly) exposed packets and outgoing TTLs. 


We also note here that signaling the LSP type (Pipe, Short Pipe or 
Uniform Model) is out of the scope of this document, and that is also 
not addressed in the current versions of the label distribution 
protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP]. Currently, 
the LSP type is configured by the network operator manually by means 
of either a command line or network management interface. 


2.3. New Terminology 


iTTL: The TTL value to use as the incoming TTL. No checks are 
performed on the iTTL. 


oTTL: This is the TTL value used as the outgoing TTL value (see 
section 3.5 for exception). It is always (iTTL - 1) unless otherwise 
stated. 


oTTL Check: Check if oTTL is greater than 0. If the oTTL Check is 
false, then the packet is not forwarded. Note that the oTTL check is 
performed only if any outgoing TTL (either IP or MPLS) is set to oTTL 
(see section 3.5 for exception). 


3. TTL Processing in different Models 
This section describes the TTL processing for LSPs conforming to each 


of the 3 models (Uniform, Short Pipe and Pipe) in the 
presence/absence of PHP (where applicable). 
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Bis 


1. 


TTL Processing for Uniform Model LSPs (with or without PHP) 
(consistent with [MPLS-ENCAPS]): 
LSP > 

+--Swap-- (n-2)-...-swap-- (n-i) ---+ 
/ (outer header) \ 

(n-1) (n-i) 

/ \ 

SSH (i haa A EEE E a E Mencia CRY eee go) E EE bat se Odea Pop-- (n-i-1) -> 
(I) (inner header) (E or P) 


(n) represents the TTL value in the corresponding header 
(x) represents non-meaningful TTL information 

(I) represents the LSP ingress node 

(P) represents the LSP penultimate node 

(E) represents the LSP Egress node 


This picture shows TTL processing for a Uniform Model MPLS LSP. Note 
that the inner and outer TTLs of the packets are synchronized at 
tunnel ingress and egress. 


TTL Processing for Short Pipe Model LSPs 
sabe TTL Processing for Short Pipe Model LSPs without PHP 
LSP > 
+--Swap-- (N-1)-...-swap-- (N-i) ----- + 
/ (outer header) \ 
(N) (N-i) 
/ \ 
Pe SN) p Sa a a aa CD) a r a a ea eet ai Pop-- (n-2) -> 
(I) (inner header) (E) 
(N) represents the TTL value (may have no relationship to n) 
(n) represents the tunneled TTL value in the encapsulated header 
(I) represents the LSP ingress node 
(E) represents the LSP Egress node 
The Short Pipe Model was introduced in [MPLS-DS]. In the Short Pipe 


Model, the forwarding treatment at the egress LSR is based on the 
tunneled packet, as opposed to the encapsulating packet. 
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Bic D372. TTL Processing for Short Pipe Model with PHP: 
LSP > 
+-Swap- (N-1)-...-swap-(N-i) -+ 
/ (outer header) \ 
(N) (N-i) 
/ \ 
2 SM) AA PUsS hws Saat Se ee se CTSA S's, a apcdech ah E Pop- (n-1) -Decr.-(n-2) -> 
(I) (inner header) (P) (E) 
(N) represents the TTL value (may have no relationship to n) 
(n) represents the tunneled TTL value in the encapsulated header 
(I) represents the LSP ingress node 
(P) represents the LSP penultimate node 
(E) represents the LSP egress node. 


Since the label has already been popped by the LSP’s penultimate 


node, 


Also note that at the end of the Short Pipe Model LSP, 
tunneled packet has been decremented by two, 


the LSP egress node just decrements the header TTL. 


3.3. TTL Processing for Pipe Model LSPs (without PHP only): 


the TTL of the 
with or without PHP. 


LSP > 
+--Swap-- (N-1)-...-swap-- (N-i) ----- + 
/ (outer header) \ 
(N) (N-i) 

/ \ 
SSS) SS PST EAE E EE CL) So oe ella Sa Sie eS ote n ate Pop-- (n-2) -> 
(I) (inner header) (E) 

(N) represents the TTL value (may have no relationship to n) 

(n) represents the tunneled TTL value in the encapsulated header 
(I) represents the LSP ingress node 

(E) represents the LSP Egress node 


From the TTL perspective, 


identical to the Short Pipe Model without PHP. 
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3.4. Incoming TTL (iTTL) determination 


If the incoming packet is an IP packet, then the iTTL is the TTL 
value of the incoming IP packet. 


If the incoming packet is an MPLS packet and we are performing a 
Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming 
label. 


If the incoming packet is an MPLS packet and we are performing a Pop 
(tunnel termination), the iTTL is based on the tunnel type (Pipe or 
Uniform) of the LSP that was popped. If the popped label belonged to 
a Pipe Model LSP, then the iTTL is the value of the TTL field of the 
header, exposed after the label was popped (note that for the purpose 
of this document, the exposed header may be either an IP header or an 
MPLS label). If the popped label belonged to a Uniform Model LSP, 
then the iTTL is equal to the TTL of the popped label. If multiple 
Pop operations are performed sequentially, then the procedure given 
above is repeated with one exception: the iTTL computed during the 
previous Pop is used as the TTL of subsequent labels being popped; 
i.e. the TTL contained in the subsequent label is essentially ignored 
and replaced with the iTTL computed during the previous pop. 


3.5. Outgoing TTL Determination and Packet Processing 


After the iTTL computation is performed, the oTTL check is performed. 
If the oTTL check succeeds, then the outgoing TTL of the 
(labeled/unlabeled) packet is calculated and packet headers are 
updated as defined below. 


If the packet was routed as an IP packet, the TTL value of the IP 
packet is set to oTTL (iTTL - 1). The TTL value(s) for any pushed 
label(s) is determined as described in section 3.6. 


For packets that are routed as MPLS, we have four cases: 


1) Swap-only: The routed label is swapped with another label and the 
TTL field of the outgoing label is set to oTTL. 


2) Swap followed by a Push: The swapped operation is performed as 
described in (1). The TTL value(s) of any pushed label(s) is 
determined as described in section 3.6. 


3) Penultimate Hop Pop (PHP): The routed label is popped. The oTTL 
check should be performed irrespective of whether the oTTL is used 
to update the TTL field of the outgoing header. If the PHPed 
label belonged to a Short Pipe Model LSP, then the TTL field of 
the PHP exposed header is neither checked nor updated. If the 
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PHPed label was a Uniform Model LSP, then the TTL field of the PHP 
exposed header is set to the oTTL. The TTL value(s) of additional 
labels are determined as described in section 3.6 


4) Pop: The pop operation happens before routing and hence it is not 
considered here. 


3.6. Tunnel Ingress Processing (Push) 


For each pushed Uniform Model label, the TTL is copied from the 
label/IP-packet immediately underneath it. 


For each pushed Pipe Model or Short Pipe Model label, the TTL field 
is set to a value configured by the network operator. In most 
implementations, this value is set to 255 by default. 


3.7. Implementation Remarks 


1) Although iTTL can be decremented by a value larger than 1 while it 
is being updated or oTTL is being determined, this feature should 
be only used for compensating for network nodes that are not 
capable of decrementing TTL values. 


2) Whenever iTTL is decremented, the implementer must make sure that 
the value does not become negative. 


3) In the Short Pipe Model with PHP enabled, the TTL of the tunneled 
packet is unchanged after the PHP operation. 


4. Conclusion 
This Internet Document describes how the TTL field can be processed 
in an MPLS network. We clarified the various methods that are 
applied in the presence of hierarchical tunnels and completed the 
integration of Pipe and Uniform Models with TTL processing. 


5. Security Considerations 


This document does not add any new security issues other than the 


ones defined in [MPLS-ENCAPS, MPLS-DS]. In particular, the document 
does not define a new protocol or expand an existing one and does not 
introduce security problems into the existing protocols. The authors 


believe that clarification of TTL handling in MPLS networks benefits 
service providers and their customers since troubleshooting is 
simplified. 
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9. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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